Phase A2 of the admin console plan — closes the long-standing
TenantService gap so the admin-ui Tenants page has something to call.

tenant-api:
- TenantMetadata (record: id + name + mode + active + createdAt)
- TenantService (interface: create / rename / activate / deactivate /
  delete / findById / findAll)

tenant-core:
- PlatformTenantEntity (id varchar(64) PK = TenantId slug,
  name, mode (SINGLE/MULTI), active, created_at)
- JpaPlatformTenantRepository
- DefaultTenantService implementation
- new deps: spring-boot-starter-data-jpa, lombok (compileOnly)
- db/migration/V7__platform_tenant.sql

autoconfigure:
- TenantAutoConfiguration grows a @ConditionalOnBean(JpaPlatformTenantRepository.class)
  + @ConditionalOnMissingBean TenantService bean. Apps without JPA on
  the classpath still get TenantContextHolder + TenantResolver but no
  TenantService.

admin-api:
- TenantAdminController under /admin/api/v1/tenants:
  POST /        create
  GET  /        list
  GET  /{id}    fetch
  PUT  /{id}    rename
  PUT  /{id}/activate, /deactivate
  DELETE /{id}
- CreateTenantRequest, RenameTenantRequest DTOs (Jakarta Validation)

Design note: platform_tenant.id stays a varchar(64) slug rather than
UUID so existing tables that already carry tenant_id as a string slug
keep working without FK migration churn. Consumer apps that want strict
referential integrity can add the FK in their own migration.

Verified: ./gradlew :devslab-kit-sample-app:test  -> BUILD SUCCESSFUL in 56s
- V7 applies cleanly on top of V1-V6
- TenantService bean wires (JpaPlatformTenantRepository present)
- All previous beans, login flow, admin-api controllers still green